@tyeth is this blocking on anything?

In theory it's not blocked, and I tested fine on the esp8266 which I'd wanted to verify worked with the square root float function.

In my initial writing+testing on another device (s3) I had the sensor not behaving as expected in normal mode, the gauss value was flatlining with the same high signal, starting at the correct value and dropping rapidly in the next reading, but working fine in continuous mode. I also saw it refuse to return data in one boot cycle (all readings not high enough / valid).
It seemed to behave entirely fine in continuous mode.
Then reading the data sheet the application example includes setting register 0x29 to value 0x06 to set the sign for x/y/z, but the register 0x29 is not mentioned anywhere else in the datasheet (only in each one of the application examples). It's also not used in our library at all. I tried setting that value of 06 to register 29, and it took it, read back fine. Normal mode also seemed to work fine.
Not got any further with that bit as I couldn't then unset it having forgot to get the value before setting it on my first test.
The datasheet also spoke about the order of commands being different to the example in our driver, with mode set last, so I should probably test that once/if I can recreate the bad values situation.

It's taken me 2days to find the other QMC chip which is untouched in theory, so I can check the value of that register before setting it, and see if normal mode behaves weirdly.

I've got uncommitted changes locally right now, but just a brutal loop on isDataReady with serial print which never failed ever. I'll check the 2nd unit tomorrow, but worth you ordering one @brentru

@tyeth This seems like an issue with the QMC driver library, not WS.

Could you blackbox test it against the example sketch, narrow down what is happening, and post it on our QMC driver library and tag @ladyada so she can take a look?

Yeah nothing useful really from testing arduino example. The second sensor I have showed the default value for the undocumented Sign of X/Y/Z register (0x29) showed an initial value of 0 rather than 0x06 as the datasheet application examples showed should be set.
Running in continuous mode seems to be the best plan for now, but I've documented the issues seen and will make an enquiry about the register 29H mentioned in the datasheet application examples.

@brentru this is ready for review (and unblocked)

I've moved the math.h include as suggested (thanks), and explained I'd prefer to keep the XYZ logging for now in v1 as the user is likely to want to see it when things go wrong.
@brentru you happy for me to merge this now?